Git Kata 7: Collaboration as Carrie

Learn about two contributors pushing commits to a shared repository.

We'll cover the following

Step 3: Make changes as Carrie and push#

In the Carrie window below is the command to open a file in the text editor:

Command's Parameters

Command / Parameter

Description

nano

This opens the text editor.

storelist.htm

This is the file to be edited.

Carrie opens her copy of storelist.htm in her local repository.

To change and save the file:

  • Replace “Enter list here…” with three items out of order from the Main List.
  • Save the changes.
Before replacing "Enter list here..." with three items out of order from the Main List
Before replacing "Enter list here..." with three items out of order from the Main List

1 of 2

After replacing "Enter list here..." with three items out of order from the Main List
After replacing "Enter list here..." with three items out of order from the Main List

2 of 2

Carrie is in a hurry, so she grabs a few items from the Main List and throws them into the Next List without taking the time to put them in the correct order. Ken will have to take care of that later.

The command to commit the changes is given below.

Command's Parameters

Command / Parameter

Description

commit

This creates a new commit in the repository.

-a

This stages all the modified files to the index prior to creating the commit.

-m

The -m parameter allows the commit message to be defined on the command line instead of opening a text editor.

"Adding some items, list is out of order"

This is the commit message.

Carrie commits her additions to storelist.htm to the index of her local repository.

The output of the command is:

Output

Message

Meaning

"[master 3072226] Adding some items, list is out of order"

This is the branch, commit hash, and commit message of the commit

"1 file changed, 5 insertions(+), 2 deletions (-)"

This is a summary of the changes included in the commit (the next line is output from the text editor and can be ignored).

The command to push the changes is given below.

  • Enter “carrie.coder” as username (if prompted for username).
  • Enter “katas” as a password.

Carrie attempts to push her changes to the remote repository, but the push is rejected. The message is very explicit and explains exactly why the push was rejected: Git will reject a push if the local branch is missing commits that are present in the remote. If this push were accepted, it would be “out of order” in the remote’s history, and Ken’s changes wouldn’t be present in future commits. It’s possible to force a push, but for obvious reasons, that’s usually not considered a best practice.

Ken’s commit from the previous steps isn’t present in Carrie’s local repository. Carrie needs to get that commit to synchronize her local repository with the remote. She will then be able to push to the web-storelist repository in the Gogs server.

The output of this command is:

Output

Message

Meaning

"To https://ed-6091404232622080.educative.run:3000/devops/web-storelist"

This is the URL to the remote repository.

"! [rejected] master -> master (fetch first)"

This is the result of the attempt to push. Git indicates that we should “fetch first.” The git fetch command will be explained in the next step.

"error: failed to push some refs to

'https://ed-6091404232622080.educative.run:3000/devops/web-storelist'"

The push failed.

The command to display the status of the repository is given below.

Command's Parameter

Command / Parameter

Description

status

This displays the status of the files in the working directory of the repository.

Carrie executes git status to view the status of the repository. The status reports that Carrie’s repository is ahead of origin/main, the tracking branch, by one commit. This is why the prior step’s push failed.

The output of this command is:

Output

Message

Meaning

"On branch master"

The current branch is main.

"Your branch is ahead of ‘origin/master’ by 1 commit. (use “git push” to publish your local commits)"

There's one commit in the local repository that's not in the remote. This means the local branch is “ahead” of the remote branch by the commit Carrie just made, adding her items.

"nothing to commit, working tree clean"

There are no uncommitted changes in the local repository. This is distinct from the difference between the local repository and the remote repository.

Pull Ken’s changes to Carrie’s local repository using the following command:

Command's Parameter

Command / Parameter

Description

pull

The git pull command retrieves commits from a remote repository branch, puts them in the local tracking branch, and merges the tracking branch with the local branch.

Carrie uses git pull to retrieve Ken’s commit. The git pull command is a shorthand that combines two commands: git fetch and git merge.

The git fetch command updates the local tracking branch with the commits from the remote repository. The git fetch command can be run by itself to update the tracking branch without applying the commits to the local branch. This is useful in cases where we want to see the differences between the branches but aren’t ready to merge them.

The other half of the git pull command is git merge FETCH_HEAD. We’ve seen what git merge does in previous katas; it takes commits from one branch and applies them to another. The FETCH_HEAD command is a temporary ref in the tracking branch. The git merge FETCH_HEAD operation takes the commits from the tracking branch and applies them to the current local branch, completing the git pull operation.

The output of this command is:

Outputs

Message

Meaning

"remote: Counting objects: 5, done

remote: Finding sources: 100% (3/3)

remote: Getting sizes: 100% (3/3)

Unpacking objects: 100% (3/3), done.

remote: Total 3 (delta 1), reused 3 (delta 1)"




This is a summary of the download operation.

"From http://localhost:8000/devops/web-storelist b852f3d..8603f17 master -> origin/master"


This is the URL of the remote repository, the hashes of the refs, and the local and remote branches

"Auto-merging storelist.htm"

Git will try to auto-merge the file.

"CONFLICT (content): Merge conflict in strorelist.htm"

Git was unable to auto-merge because of a merge conflict.

"Automatic merge failed; fix conflicts and then commit the result."

The merge conflict will have to be manually resolved.

To resolve the conflicts and save the file:

  • Switch back to the text editor.
  • Reload Carrie’s copy of storelist.htm.
  • Resolve the conflicts (remove the conflict headers so that all six items are in the list).
  • Save the changes.
Before removing the conflict header
Before removing the conflict header

1 of 2

After removing the conflict header
After removing the conflict header

2 of 2

As we’ve seen in previous katas, Git cannot automatically merge conflicting changes on the same lines of the same file. Carrie does a quick combine of the lists simply by removing the conflict headers and leaving all six items in the Next Visit list.

The command to commit the changes is given below.

Command's Parameters

Command / Parameter

Description

commit

This creates a new commit in the current branch.

-a

This stages all the modified files prior to the commit.

-m

This sets a commit message on the command line.

"Combining our lists"

This is the commit message.

Carrie removes the conflict headers, thus resolving the merge conflict. All six items are now in the Next Visit list.

The command to push the changes is given below.

Command's Parameters

Command / Parameter

Description

push

This sends commits on the designated branch to a remote repository.

-u

The `-u` parameter is short for `--set-upstream`. This option creates a tracking branch between the local and remote branches.

origin

The name of the remote to which the pushed commits will be sent.

master

The name of the local branch from which to send the commits.

Now that Carrie has manually resolved the conflicts and committed them to her local repository, she can push the commits to the remote repository.

The output of this command is:

Message

Meaning

"Counting objects: 6, done.


Compressing objects: 100% (6/6), done.

Writing objects: 100% (6/6), 706 bytes 0 bytes/s, done.

Total 6 (delta 2), reused 0 (delta 0)

remote: Resolving deltas: 100% (2/2)

remote: Updating references: 100% (1/1)"





Git counts all the objects that will be included in the push. Objects include files, refs, and blobs (binary large object), which is the raw “image” of a file.

Git compresses and then sends the objects to the remote repository.

"To http://localhost:8000/devops/web-storelist.git"

This is the URL of the remote repository.

"8603F17..03a73a8"

These are the hashes of the local and remote refs.

"master -> master"

This is the local and remote branches.

"Branch master set up to track remote branch master from origin."

The local main branch is tracking the remote main branch.

Step 4: Final edits as Ken#

In the Ken window below is the command to display and update Ken’s remote repository:

Commands

Command / Parameter

Description

status

This displays the status of the files in the working directory of the repository.

remote update

The git remote update command is the equivalent of calling git fetch on every local branch. This updates the index to match the remote without affecting the working directory.

status

This displays the status of the files in the working directory of the repository.

This sequence of commands demonstrates how git remote update can be used to determine whehter there are commits in the remote repository that haven’t been retrieved with git pull.

First, Ken executes git status to look at the status of his local repository. Git reports that everything is up-to-date; however, we know that’s not the case. Carrie has pushed her commit since the last time Ken pushed his. The remote repository branch is ahead of Ken’s local, but Git doesn’t know that yet.

The output of git status is:

Output

Message

Meaning

"On branch master"

The current branch is main.

"Your branch is up-to-date with ‘origin/master’."

Ken hasn't yet executed any commands that will refresh the status of the remote tracking branch, so Git reports that the local repository is up-to-date. The next command will refresh this tracking branch.

"nothing to commit, working tree clean"

There are no uncommitted changes in the local working directory.

Ken then uses git remote update to update the local tracking branch. This command updates all the remote tracking branches. The local repository tracking branch refs are updated, but the newly downloaded commits aren’t applied to the working directory.

The output of git remote update is:

Output

Message

Meaning

"remote: Counting objects: 10, done

remote: Finding sources: 100% (6/6)

remote: Getting sizes: 100% (6/6)

Unpacking objects: 100% (6/6), done.

remote: Total 6 (delta 2), resued 6 (delta 2)"




These are the statistics of the git fetch operation.

"From http://localhost:8000/devops/web-storelist"


This is the URL of the remote.

"8063f17..03a73a8"

These are the hashes of the local and remote refs.

"master -> origin/master"

These are the names of the local and remote refs.

Finally, Ken executes git status again. Git now accurately reports that his local repository is behind the remote repository by two commits.

The output of this execution of git status is:

Output

Message

Meaning

"On branch master"

The current branch is main.

"Your branch is behind ‘origin/master’ by 2 commits and can be fast-forwarded. (use “git pull” to update your local branch)"

The local tracking ref has been updated, so Git now reports that the local main branch is two commits behind the remote `main` branch. Git also reports that the local branch can be fast-forwarded. This means that git pull will download the commits from the remote and execute a fast-forward merge.

"nothing to commit, working tree clean"

As before, there are no uncommitted changes in the working directory.

The command to pull the commits is given below:

Commands

Command / Parameter

Description

pull

The git pull command retrieves commits from a remote repository branch and applies them to a local branch.

Ken executs the git pull command, which downloads the commits from the remote repository and merges them with the current branch. As indicated in the previous step, Git performs a fast-forward merge with FETCH_HEAD.

To change and save the files:

  • Switch to text editor and reload Ken’s copy of storelist.htm.
  • Copy and paste to reorder the items in the correct order.
  • Save the changes.
Before copying and pasting items in the correct order
Before copying and pasting items in the correct order

1 of 2

After copying and pasting items in the correct order
After copying and pasting items in the correct order

2 of 2

Ken now has the full list of grocery items, but the list is out of order. Ken opens the storelist.htm file in his local repository and reorders them to match the order in the Main List.

The command to display the status of the repository is given below:

Command's Parameter

Command / Parameter

Description

status

This displays the status of the files in the working directory of the repository.

Ken has reordered the list, modifying storelist.htm. That’s now the one uncommitted change in the working directory.

The output of git status is:

Output

Message

Meaning

"On branch master"

The current branch is main.

"Changes not staged for commit: (use “git add <file>...” to update what will be committed) (use “git checkout --<file>...” to discard changes in working directory)"             



The list of changes below this message have not been staged for commit.

"modified: storelist.htm"

The change to storelist.htm has not been staged.

"no changes added to commit (use git add and/or git commit -a)"

There are changes in the working directory that must be staged in order to be included in the next commit.

The command to commit the changes is given below:

Command's Parameters

Command / Parameter

Description

commit

This creates a new commit in the repository.

-a

This stages all the modified files to the index prior to creating the commit.

-m

The -m parameter allows the commit message to be defined on the command line instead of opening a text editor.

"Reordered the list, time for a trip!"

This is the commit message. It must be enclosed in quotes.

Ken commits the reordered list to his local repository.

The output of this command is:

Output

Message

Meaning

"[master 49b7e3f] Reordered the list, time for a trip!"

This is the branch, commit hash, and the commit message.

"1 file changed, 3 insertions(+), 3 deletions(-)"

This is a summary of the changes included in the commit

The command to push the changes is given below.

Command's Parameters

Command / Parameter

Description

push

This sends commits on the designated branch to a remote repository.

-u

The -u parameter is short for --set-upstream. This option creates a tracking branch between the local and remote branches.

origin

This is the name of the remote to which the pushed commits will be sent.

master

This is the name of the local branch from which the commits are sent.

Ken pushes the reordered list to the remote repository.

The output of the command is:

Output

Message

Meaning

"Counting objects: 3, done.

Compressing objects: 100% (3/3), done.

Writing objects (3/3), 362 bytes | 0 bytes/s, done.

Total 3 (delta 1), reused 0 (delta 0)

remote: Resolving deltas: 100% (1/1)

remote: Updating references: 100% (1/1)"






This is a summary of the files sent.

"To http://localhost:8000/devops/web-storelist.git"


This is the URL of the remote to which the commits were sent.

"03a73a8..49b7e3f master -> master"

These are the commit hashes of the local and remote branches.

"Branch master set up to track remote branch master from origin."

The main branch in the local repository is tracking the main branch in the remote.

The grocery list is now complete. Ken and Carrie have both entered their items, and Ken made sure the Next Visit list is in the correct order. The final list has been committed to the remote repository.

Git Kata 7: Collaboration as Ken

Git Kata 8: Repository Forking and Pull Requests